Thanks for the PR!

I have a couple notes. Overall using a cargo feature is the correct design. Do note that I port all commits back into the kernel (but only for the files that are there), so please follow the commit message conventions from there.

I do think that we should also think about which other types could make use of implementing the trait that you introduce here.

In core we could additionally implement it for Option, ManuallyDrop and MaybeUninit (although MaybeUninit would probably be simpler to just initialize it after the PinInit in many cases).

In std we could implement it for the Mutex, Cell and RwLock family of types.

In the kernel for Opaque although if this is needed its probably a misuse of Opaque anyways.

Split this into three commits:

1. Format Cargo.toml.
2. Add the trait and UnsafeCell implementation.
3. Add the unsafe-pinned cargo feature.

Thanks for the PR!
I have a couple notes. Overall using a cargo feature is the correct design. Do note that I port all commits back into the kernel (but only for the files that are there), so please follow the commit message conventions from there.
I do think that we should also think about which other types could make use of implementing the trait that you introduce here.

In core we could additionally implement it for Option, ManuallyDrop and MaybeUninit (although MaybeUninit would probably be simpler to just initialize it after the PinInit in many cases).

MaybeUninit is the most important one IMO. ManuallyDrop normally is stored on the stack and thus it isn't as useful. Option might be useful, but feel free to leave that for a future PR.

In std we could implement it for the Mutex, Cell and RwLock family of types.

I don't think it's worth it for Mutex/RwLock. Cell needs to store Copy types to be useful and those rarely have a pin-initializer, so I also feel like it's better to add that when someone is using it.

In the kernel for Opaque although if this is needed its probably a misuse of Opaque anyways.

Why? We already have the pin_init function there.

Ah and one more thing, could you add the information about the feature gate to the readme and include an entry in the changelog? Thanks!

Should I do that as a separate commit?

In core we could additionally implement it for Option, ManuallyDrop and MaybeUninit (although MaybeUninit would probably be simpler to just initialize it after the PinInit in many cases).

MaybeUninit is the most important one IMO. ManuallyDrop normally is stored on the stack and thus it isn't as useful. Option might be useful, but feel free to leave that for a future PR.

I'll add MaybeUninit here then.

In std we could implement it for the Mutex, Cell and RwLock family of types.

I don't think it's worth it for Mutex/RwLock. Cell needs to store Copy types to be useful and those rarely have a pin-initializer, so I also feel like it's better to add that when someone is using it.
Possibly useful for RefCell, but yeah best to wait until someone has a use-case.

In the kernel for Opaque although if this is needed its probably a misuse of Opaque anyways.

Why? We already have the pin_init function there.

I guess its useful, I was mostly thinking that Opaques usually shouldn't be used (much) from the Rust side, I didn't think about cases where the C side needs pinning.